The function of ‘Service Chaining’ is well known and various solutions are described. This function provides the means to steer subscriber traffic (e.g. mobile subscriber traffic or fixed subscriber traffic) through a set of predefined service nodes that adds value to the flow processing either to the advantage of the operator or to the advantage of the subscriber, or both.
As an example the following use cases are given:                Parental Control: the subscriber requested a ‘Parental Control’ service from the operator. All traffic from the subscriber is passed through a service node providing ‘parental control’ function, for example the service filters traffic to prohibited web-pages.        Header Enrichment: for internal purposed (e.g. simplified subscriber authentication, statistic, charging) the operator wants to enrich each HTTP request with additional information. Therefore, all traffic is sent through a Header Enrichment service before it is passed forward to the target specified in the packet.        
Note that in both use cases listed above and in general for all service chaining use cases the traffic flow is sent to a target node that is not identical with the service node. One service chaining solution uses the capability of SDN (Software Defined Networks) to dynamically associate traffic flows, i.e. data packet flows, to specific service chains. In this case the operator can define sequences of services (service chains) and how subscriber flows shall be mapped to those service chains. Then the traffic flow is steered by the SDN solution based on subscriber subscription information, subscriber session information, or other information to the appropriate service node.
Preferably a service node as service providing module shall only process ‘relevant’ traffic. That means only traffic that can be treated in the service should be sent to the service node. For example: only video traffic should be sent to a video optimizer. Any non-video traffic should by-pass the video optimizer.
Some services intercept the traffic flows in a way that they cannot be removed form a service chain without interrupting the end-to-end connection. For example a service may intercept a TCP (Transmission Control Protocol) connection and establishes separate TCP connections towards the subscriber and the target originally addressed by the subscriber. In this case the service cannot be removed for the connection without interrupting it. As a consequence the subscriber may reestablish a new connection but then this new flow is again intercepted by the service. If the service shall be removed again then the situation is the same as before: removing the service is not possible without interrupting the end-to-end connection. Such a service is called in the following a non-TCP-transparent service.
Further the specific traffic type is frequently not known at flow establishment. For example if a flow is a video flow is only known after a DPI (Deep Packet Inspection) device investigated the first packets of the flow.
In the following it is assumed that the operator owns a non-TCP-transparent service and he expects that only relevant traffic shall be sent to the service providing module. However in this case it is assumed that the first packets of a flow have to be inspected in order to decide if traffic is relevant for the service or not. An example of such a service is a video optimizer. It is assumed that first the traffic is sent through DPI and the non-TCP-transparent service, here a video optimizer. As soon as DPI classifies the traffic as non-video it is not possible anymore to remove the service from the chain.
Assuming that first the traffic is sent through the DPI but bypasses the non-TCP-transparent service. As soon as the DPI classifies the traffic as video traffic it can change the service chain and send the flow through the non-TCP-transparent service. However, the TCP connection is already established. It is questionable if the service can intercept the connection. Further, in case of a video optimizer, this service would need the first frames sent at the start of a connection to act correctly because some video stream contains important information about the stream that are needed for optimization. As a consequence the video optimizer likely fails to work when the flow is sent to the video optimizer after connection establishment.
It shall be understood that due to the fact that today traffic is frequently cached in a network it is not obvious if a packet destination is a video server or not. In addition, the destination of a packet may provide video service in some cases and non-video service in other cases. Consequently traffic cannot be steered to a service, for example video optimizer, just based on destination address.
In view of the above said, a need exists to enhance the insertion or removal of a service provided by a service providing module for a data packet flow in a service network.